Add more workflow file linting with Zizmor#9767
Add more workflow file linting with Zizmor#9767johnbillion wants to merge 22 commits intoWordPress:trunkfrom
Conversation
# Conflicts: # .github/workflows/reusable-phpunit-tests-v3.yml
| with: | ||
| script: | | ||
| const prNumbers = ${{ steps.linked-prs.outputs.result }}; | ||
|
|
There was a problem hiding this comment.
This combines two steps into one to avoid the need to pass the prNumbers between them.
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
# Conflicts: # .github/workflows/phpunit-tests.yml # .github/workflows/reusable-cleanup-pull-requests.yml
|
After having used GitHub Code Scanning on several other projects over the last year or so, I've noticed that it's a bit too easy for code scanning alerts to go unnoticed. If the default branch allows direct pushes without the commits going via a PR (or in the case of wordpress-develop, commits being mirrored in from svn) or if code scanning tools aren't included in branch protection rules then they can go unnoticed. If you push directly to the default branch and the code fails one of the code scanning tools, you won't see code scanning results being flagged anywhere, the workflow runs won't fail, but new alerts will quietly be added to the Security -> Code Scanning Alerts screen. Normally a GitHub project would address this with branch protection rules for PRs, but the svn mirroring means this doesn't apply. I'm tempted to switch to code scanning that causes the workflow run to fail instead of using the Code Scanning tool, but that would require a means to reliably run the workflow file linting locally and not have to depend on a GitHub Actions workflow. |
Previously:
This change:
Code scanning alerts
Like the existing Actionlint job, Zizmor reports to GitHub Code Scanning by uploading a SARIF report via the
github/codeql-action/upload-sarifaction (none of these tools use CodeQL but GitHub groups its code scanning actions under the CodeQL name).trunkwhen this gets committed. I suspect not because the PR won't get merged on GitHub. I'll handle it post merge if necessary.Todo
We already have Actionlint in place. Why do we need Zizmor?
The tools are complementary. Actionlint implements 38 checks, Zizmor implements 34 in its strictest mode, but only around 9 of the checks fully overlap. Zizmor gives us a net of about 20 new checks in its default mode, including detection of archived actions, spoofable bot conditions, problematic use of GitHub Actions features and patterns, overprovisioned secrets, git ref confusion, and unpinned actions.
Actionlint primarily focuses on correctness, with some security related audits included. Zizmor primarily focues on security.
Results
Some code scanning alerts remain after I dismissed the false positives and closed some non-critical warnings.
Errors
pull_request_targettrigger.$GITHUB_ENVand$GITHUB_OUTPUTin a bash scriptWarnings
${{ true }}instead oftrue. No security concern but needs an audit.